Distributed Tarpitting: Impeding Spam Across Multiple Servers

This paper describes an Irish ISP’s attempts to combat the abuse of resources caused by unsolicited commercial email. We describe the extension of a multicast system, used to implement POP-before-SMTP relaying, to share information about remote mail servers between multiple mail systems. The information may then be used to tarpit abusive servers – placing delays between SMTP protocol answers thus mitigating their impact on our systems. We then examine how effective this has been, and come up with some ideas for future development. We also discuss building a policy around this and other measures we use to combat spam. An ISP is in the business of sending and receiving mail – this makes slowing or blocking mail a delicate subject. Introduction & Problem Statement Unsolicited commercial email (spam) is a problem that, by now, needs no introduction. If you know about email, you know about spam. There are whole books on how to stop it, and it’s even on the nightly news [1, 2]. The spam problem from an ISP perspective is also reasonably well known – spam is expensive in terms of time spent receiving it, space spent storing it, and staff months spent dealing with complaints and the technical aspects of cleaning up after it. Our company, eircom.net, is the ISP division of eircom, the largest telecommunications provider in Ireland. It is also the largest internet provider in Ireland, serving approximately 500,000 customers. To put this in context, a recent survey estimated that around 766,000 adults in the south of Ireland use the Internet at home [3]. As such, any impact on our services is very visible – and is often reported in the media. Our problems with spam are probably fairly average – both the consistent low-level spam that slowly fills up our filesystems, and high-volume assaults1 that have at least once slowed even our recently retooled mail system solution [4]. However the impact of it, in terms of customer impression and our reputation, is relatively severe. There are any number of popular solutions for individual and group spam blocking available. The simple ones are a good start – things like: don’t run an open relay; don’t allow multiple recipients for null sender; and verify that envelope sender contains a valid domain. Yet the spammers seem to have worked around them. Using a blocking list involves handing a fair amount of responsibility and control to a third party – something that would not make for a good response to a customer unhappy with missed mail. Content analysis tools bring up privacy issues [5], cost 1Which seem to frequently come on a Friday evening or over the weekend. Ours is not always a polite adversary. a lot in processing power, and tend to require tuning for each individual recipient. Having rejected those options, we looked around for others and came upon tarpitting. The idea, when applied to SMTP, is that when a sender has triggered the tarpit, the SMTP server places an intentional delay between processing of the sender’s ‘‘RCPT TO ’’ command, and it’s ‘‘250 OK’’ response [6]. The tarpit delay is initially triggered by a particular rate of sending mail. The delay can be increased if the sender continues on sending at the maximum rate allowed. This seemed to us to be a good middle ground – it would dampen the blow of a dictionary attack2 or other high-volume mailshot from a single source, preventing server overload. If the sender turns out to be a legitimate source, we have not entirely blocked the flow of information to (or from) our customers. In either case, while the server’s performance would not reveal anything amiss, any high tarpit delay can be used to trigger an alert to our operations group – enabling them to examine the situation and decide to block the sender entirely, or remove the delay. The general customer base doesn’t see a problem, a mistakenly-captured legitimate sender is not entirely blocked, and we remain in control of the situation. An additional advantage of this approach was that it fitted easily into our existing infrastructure.